Support TCP for protocol messages#3636
Support TCP for protocol messages#3636softins wants to merge 40 commits intojamulussoftware:mainfrom
Conversation
softins
force-pushed
the
tcp-protocol
branch
3 times, most recently
from
f6e95f8 to
5e1a658
Compare
softins
force-pushed
the
tcp-protocol
branch
2 times, most recently
from
a61321d to
7ad1d1f
Compare
To provide three modes: UDP, TCP once or TCP long connection.
| bool bUseTranslation = true; | ||
| bool bCustomPortNumberGiven = false; | ||
| bool bEnableIPv6 = false; | ||
| bool bEnableTcp = false; |
There was a problem hiding this comment.
Since we'll have a long time for the 4.0 release, I'd enable it by default soon (of course once we've tested that the basics work)
There was a problem hiding this comment.
No, I disagree. It's a server-only option, and most servers operators will not need to enable TCP support. Only those running large directories or large servers will need to, and they also need to understand and configure their firewall requirements.
TCP support in the client will indeed be enabled by default, but will only take effect when talking to a directory or server that has enabled it.
If a server operator enables TCP without having configured their firewall correctly, client users could have problems as the server would advertise TCP support to the client, but the client could be unable to connect.
There was a problem hiding this comment.
Can we not give an error message or fallback procedure in case the TCP connection timed out?
There was a problem hiding this comment.
Yes, I'm sure we can. I haven't yet tested that scenario.
But it doesn't negate my view that server-side TCP support needs to be an explicit option.
Constructor for CTcpConnection made polymorphic for client and server.
3 participants
Short description of changes
Support fallback to TCP for protocol messages, in order to overcome potential loss of large messages due to UDP fragmentation. Currently an incomplete draft, for comment as development continues.
CHANGELOG: Client/Server: Support TCP fallback for protocol messages.
Context: Fixes an issue?
Discussed in issue #3242.
Does this change need documentation? What needs to be documented and how?
It will need documentation once design and development are complete. Particularly need to explain the firewall requirements for a server or directory.
Status of this Pull Request
Incomplete, still under development. Main server side complete and working. Client side
not written yetdevelopment in progress.What is missing until this pull request can be merged?
Completion and a lot of testing of both server and client. Intended for Jamulus 4.0.0.
Checklist